elements of the process are illustrated in Fig. 7F. Link software 154 preferably works with a 
timetable, which instructs it when to get information and make automatic updates to the first 
level database 153-10 (Step 755). 

Server 151 is responsible for controlling the betting events, i.e., opening and closing of 
5 betting, etc., of all of the authorized users. It receives and accepts bets that have been 
requested by the users. Server 151 retrieves the results of sports matches by accessing web 
server 140 under the control of the link software 154 and records the results in a database (not 
shovm). Users can interactively retrieve the results through server 151. Once the results are 
retrieved and stored, software on server 151 calculates wins and makes payments to the 
10 bettors. Electronic accounts stored m the UI database 702 are used for tracking betting wins 
and losses. 

In providing the betting services, the link software 154 takes the data content from the 
web page(s) 131 and 141 of web servers 130 and 140 and includes it in a first level database 
153-10 (Step 756). The data content in first level database 153-10 is used to generate a 
15 plurality of different second level databases 153-20, such as Game Database 153-21, user 

databases 153-22 to 153-24, and News database 153-25 shown in Fig. 7F. (It should be 
understood that, although the databases are referred to herein as either "first level" or "second 
level" databases, it may be such (strictly speaking) that there is only one level of data. The 
terms "first level" and "second level" are meant to refer to the functionalities that are done in 
20 the server.) Advertisements and sports analysis databases can also be generated. These and 
other databases can be used in a variety of systems, such as Gaming System 155, News 
System 156, and Sports Analyst System 157 shown in Fig. 7G. 

A particular aspect of the invention is the generation of a second-level personalization 
database 153-30 for each authorized user. Information from among the various databases is 
25 selected and then shown to the user according to personalization database 153-30 (Step 757). 

Each user may utilize any kind of Internet capable terminal device such as a computer 
160 wdth a wtfed connection (which may be a desktop computer, laptop computer, handheld 
computer, or Palm™ device) or a mobile device 190 having a wireless connection via Internet 
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access 170 in mobile network 180. The wireless connection can be made via Bluetooth, a 
Wireless Local Area Network (WLAN) or GSM/GPRS common access methods. 

Preferably, betting provider 150 either executes software which automatically 
recognizes the type of terminal used by a user and/or permits the user to identify, as part of the 
registration process, the type of terminal they will normally use, what kind of connection and 
connection speed is used and what kind of information is desired (e.g., sports). Because the 
screens of many mobile devices are small, irrelevant information can be removed so that each 
user of a mobile device gets only their desired information. For example, the user can fill out a 
questionnaire beforehand and state that they only wish to receive information and make bets 
with respect to, for example, hockey games. 

Alternatively, betting provid er 150 mav also create data stored in the personalization 
database by monitoring the use r's navigation through the browser and the betting selections 
As the user makes a request, su ch as bv chcking on an object, the server 151 registers the 
subject of the request and respo n ds with an appropriate page based on the request. The 
system can create the profile bv anal y zing and processing this historical information. Using the 
resulting history-based profile, the bett i ng provider 150 displavs the bets which best match the 
user's interests. Also, other already existing p e rsonalizing information can be used as an extra 
source to determine the user profiles. 

When a user wants to make a bet and user has already made bets before, the svstem 
may alr eady be aware of the type of bets the user likes to do or is likelv to do. These bets can 
be, for example, on a particular subi e ct. such as footbaU. hockey, etc. and what specific team 
or teams of interest to the user, or if the user is more likelv to bet on the home team than the 
visitor team. 

The system preferably creates the pro fi le in the personalization database for every user 
it identifies and actively updates t h e personalization information according to the user's 
actions. The identification can be a c cording to user identity and a corresponding pa.ssworH 
Alternatively, if a user uses a d evice that r equires a PTN (Personal Identification Number^ and 
has some kind of SIM CSuhscriber Identi fi cation Module) or equivalent, the svstem can e?»si1y 
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identify the person using the device. The password to the betting system may be unnecessary 
because the system can identify the u ser according to the predetermined identification 
information (i.e.. PIN & SIM informationV 

Video and audio streaming of an on-going competition on which viewers may bet is 
accomplished, in the preferred embodiments, through use of a live video/audio streaming 
server (VAS) 118. The VAS is connected to a network such as an extranet, intranet, or the 
Internet 1 16. A live broadcast 120 of a competition is received through an RF receiver at the 
server. The audio and video components of the signal are separated and digitized. The 
digitized audio is then compressed using one of several digital compression schemes, for 
example, H.728, H.729, or GSM. Likewise the digitized video is compressed using a scheme 
such as MPEG, MVC, H.261, etc. The digitally compressed audio and video are packaged for 

^; network transfer e.g., TCP/IP, UDP. The packets are then broadcast to the network 116 

I £ controlled by a streaming/multicasting controller. 

;^ The mobile betting client 102 has PIP functionality. This functionality allows the 

m viewer to simultaneously view two audioAddeo broadcasts in the display of the mobile betting 
^ 4 client. The two broadcasts can be, for example, the live-feed of a competition in one picture 
and interactive betting possibilities in another. 

Figure 5 is a diagram depicting a possible interactive display. Directions at the top of 
1=.^ the display 502 inform the viewer of the status or title of the interactive activity, in this case, 
betting. For an apphcation such as betting, a dialog-type box 504 is used to inform the viewer 
of the current question on which bets can be placed. In the context of an auto race, a question 
such as "Who will turn the fastest 13th lap" may be presented. A pull-down menu or radio 
button dialog box 506 may be presented depending on the type of question. In the above 
example, aU of the drivers remainmg in the race may be presented in a pull-down menu. 
Dialog boxes specific to wagering: stakes 508; odds 510; and payout 512, may also be 
presented. A statement of account 514 with a betting services provider may also be presented. 
The account is dynamic throughout the competition, registering winnings and debits as each 
occurs. A response dialog 516 informing the user of bets being received and the current 
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